In modern computing, many tasks which can be performed on a computer require some level of security. In order to provide a level of security, there are several options. One is to perform all secure applications on a computer which is completely separate from any possibly insecure elements, or to use a virtual machine monitor (VMM) to allow complete separation between two execution environments (e.g. operating systems) running on a single computer system. However, this may be impractical. There may be a need, for cost or convenience reasons, for a secure execution environment to share resources with applications with unassured security, and those applications and those resources may be vulnerable to an attacker. Additionally, where a VMM is used, since a VMM requires full virtualization of the machine and all of its devices (thereby requiring that the VMM provide its own device driver for every possible device), a VMM is not well suited to an open architecture machine in which an almost limitless variety of devices can be added to the machine.
One way to provide the ability to share resources among two execution environments is to provide a computer system in which there is one “main” operating system that controls most processes and devices on a machine, and where a second operating system also exists. This second operating system is a small, limited-purpose operating system alongside the main operating system which performs certain limited tasks. One way to make an operating system “small” or “limited-purpose” is to allow the small operating system to borrow certain infrastructure (e.g., the scheduling facility, the memory manager, the device drivers, etc.) from the “main” operating system. Since a VMM effectively isolates one operating system from another, this sharing of infrastructure is not practical using a VMM.
Certain other techniques allow operating systems to exist side-by-side on the same machine without the use of a VMM. One such technique is to have one operating system act as a “host” for the other operating system. (The operating system that the “host” is hosting is sometimes called a “guest.”) In this case, the host operating system provides the guest with resources such as memory and processor time. Another such technique is the use of an “exokernel.” An exokernel manages certain devices (e.g., the processor and the memory), and also manages certain types of interaction between the operating systems, although an exokernel—unlike a VMM—does not virtualize the entire machine. Even when an exokernel is used, it may be the case that one operating system (e.g., the “main” operating system) provides much of the infrastructure for the other, in which case the main operating system can still be referred to as the “host,” and the smaller operating system as the “guest.” Both the hosting model and the exokernel model allow useful types of interaction between operating systems that support sharing of infrastructure.
Thus, these techniques can be used to provide a computer system with at least two execution environments. One of these may be a “high-assurance” operating system, referred to herein as a “nexus.” A high-assurance operating system is one that provides a certain level of assurance as to its behavior. For example, a nexus might be employed to work with secret information (e.g., cryptographic keys, etc.) that should not be divulged, by providing a curtained memory that is guaranteed not to leak information to the world outside of the nexus, and by permitting only certain certified applications to execute under the nexus and to access the curtained memory.
In a computer system with two execution environments, one of which is a nexus, it may be desirable for the nexus to be the guest operating system, and a second operating system, not subject to the same level of assurance as to behavior, to be the host operating system. This allows the nexus to be as small as possible. A small nexus allows a higher level of confidence in the assurance provided by the nexus. Therefore operating system functions be run by the host operating system.
One such operating system which may be run by the host operating system is a windowing system. When using a windowing system, a user's display will be populated with windows, areas on the screen which display information from an application. An application may have one or more windows. One window of all the windows displayed may have focus. The focus window may be indicated by a different border around the window, for example.
In traditional windowing systems, when a window has focus, it is generally the object of the user's input. Therefore, if a user types information using a keyboard, in many cases, the keystroke data will be sent by the operating system to the application which owns the window which has focus. Some keystrokes and other input actions may not be sent to the application which owns the window with focus. For example, in some windowing systems there is a keystroke command which minimizes all windows. Such a command will be handled by the windowing system, and not sent to the application owning the window with focus. The application owning the focused-on window may receive notification of the minimization of the window; however, the user keystrokes are intended for the windowing system, not the application owning the window having focus, and will not be sent to that application.
When the windowing system is run by the host operating system, rather than by the nexus, it is vulnerable to attack. This causes a problem because, as described, the windowing system tracks which window will receive user input by tracking which window has focus. Therefore an attack can be mounted on the system by shifting the focus without the user noticing, or even without indications which the user can notice.
An attack may occur, for example, via a program running on the host which switches the focus and captures keystrokes. The user is led to believe that the user's input will be directed towards a trustworthy entity—some hardware, system software, application, or window which is running in the nexus. However, at some point the focus shifts. The user input instead is being directed to the attacking program, where it is captured and may be used later.
Thus, because the windowing system is under the control of the host operating system and the user's input is generally directed to the window having focus at the time of the input, the high-assurance nature of the nexus is imperiled. Although the invention is described with reference to a windowing system, there may be other systems in which there are two or more levels of assurance, and where a user may choose which entity (e.g. an application) to interact with. In these systems, as well, certain input must be kept secure from lower-assurance applications and entities, and the same problems described above occur.
In view of the foregoing there is a need for a system that overcomes the drawbacks of the prior art.